Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1599/1433

Internet Message Format | 1994-08-27 | 8.1 KB

Date: Sun, 22 May 94 23:10 CDT
From: [e-mail] (Evan K. Langlois)
To: [e-mail]
Subject: Domain X


I'll start calling this Domain X (as in Uni_X_ or _X_Windows) for teh sake
of brevity.

========================================================================
> I hope my intensions about the new domain are more clear.
 You should post the lastest summary to the list. :-)
 Or better: You should start implementing it! ::--))
========================================================================

This is part summary, part reply.  I can't implement it because, well,
there are a number of problems.  1 - my compiler is broke for now. 2 -
the cookiejar calls are required, and I haven't finished those because
my compiler is broke (hey! what's a good gemdos opcode for a Cookiejar
call?  I may also need 2 or 3 more opcodes for reading the system tick
without being in super-visor mode and manipulating the shell pointer as
I've always like the idea of having 1 shell for all programs to use
and being able to execute command lines through the shell using _shell_p)
Maybe a key-click/system bell control call, since it seems you need to
mess with supervisor memory to set these too.  MiNT can provide the
needed protection for these calls while making Super() practically useless.

Implementation can begin in the path2cookie() function.  The recent change
to return EPTHNF instead of EFILNF could be removed for Domain X apps.
Just test the domain before returning a value I guess.  Where else there
may be conflicts between domains is over my head.  I don't know enough about
unix, which is why i'm not the choice to implement Domain X (this is the
3rd reason, if your counting).

========================================================================
 This would result in either MiNT starting with the new domain as a default
plus a setuid program to switch "back" to GEM after some security checks are
done, because you'll then be able to start up secure as default. Or MiNT would
start as normal and you'll have to fix startup programs like 'init' or at
least 'getty' to switch to secure domain later.
========================================================================

Uhh .. second way.  Having MiNT start up pid 001 (or worse, pid 000) as
domain X would really make things difficult.  It's MUCH easier to just have
init (or your shell programs!) switch to domain X.  MultiTOS users would
certainly prefer it that way.

========================================================================
> No, I don't agree here at all. (...) Since only the super-user can switch
> from the new domain to TOS or MiNT and only a TOS or MiNT domain process
> can access GEM, and then only if you are effectively root. I think that
> is fairly secure.

 Ok, I think I've got your point.

> 1) No GEM programs should be allowed under this new mode.
>
> Agreed.

 Or do you have an idea to make fork() work with a pure 68000 system?
========================================================================

Actually, I do have a few ideas.  Since tfork() works, then Pvfork() could
be hacked up to be non-blocking.  Users of Pvfork() would have to realize
that ALL memory is shared, and all memory is owned by the PARENT application.
The user could use semaphores when necessary to protect access to sensitive
data.  This would be very useful.  Just set up the new process much like
tfork() would.

Unblocking Pfork() seems to be a problem of pointers.  A pointer in the parent
when copied to the child will access the paren't memory, not the child's
memory.  I think that if the code is base-relative, then you can adjust the
base register of the child to take care of 90% of the programs data access.
The rest is what to do with pointers that are "computed", or returned from
a malloc.  One idea is to use the memory "handle" system that DMJ is working
on (although he isn't going to do it for MiNT, he doing it for TOS/Geneva).
Basically, a new call allows you to allocate a block of memory, but instead of
a pointer to the block, you get a "handle".  To access the block, you must
"lock" it in place - this call returns a pointer.  When you are done, you
release the lock, and your pointer becomes invalid, as the manager can now
move the block, defragment memory, or swap it to disk.  Your "handle" is now
the only way to access the block .. again re-locking it and getting a new
pointer.  Such a system could help in managing pointers when forking a child.
It would also be useful in a shared memory file, since you can put handles
in the shared block, but not pointers.  It STILL may not be possible to
reliably use Pfork() on a 68000.  However, Pvfork() doesn't even need to
copy data, except maybe a copy of what is on the stack, and a new executable
format that manages stack could help here.

========================================================================
 Most of the security aspects are ridiculous if the stuff runs on a pure
68000 machine because you can almost do what you want anyways.
========================================================================

Only if you allow them to upload programs, or to access your compiler.
On a 68K, anyone would be a fool to let a remote user run GCC as you
just don't have the resources available for that.  Anyone that allows
the remote user to upload a program for a 68K would have to either trust
the user (how many users know how to get the 68K into supervisor mode without
the Super() call anyway?).  Likely, they still wouldn't do too much damage
since Super() will fail.

========================================================================
> [GEM behaving bad]

 If you silently accept to force these users to buy the newest MultiTOS in
order to be able to do something serious, you can also say: Go and get the
newest hardware, otherwise you won't be able to something serious at all.
========================================================================

I don't understand.  MultiTOS or the ROM GEM can run.  GEM programs run
in MiNT or TOS domain (providing you are the super-user or are at the local
console, depending on how you want to protect things).  I'm NOt saying people
should buy MultiTOS as Domain X shouldn't allow GEM programs anyway.

Protecting acess to XBIOS/BIOS/AES/VDI traps could be done by pointing
these traps into an internal MiNT routine when a program is run.  The first
call the program makes goes into MiNT.  If MiNT decides this program can
make the call legally, it simply assigns the pointer of the real trap routines
into that applications handler and falls through it.  This program can then
make more calls to that trap directly without going through MiNTs checking.
A child process has its traps again pointed into MiNT until a call is made.
This should allow maximum protection and only the first call to a particular
trap (such as the AES/VDI trap) to slow down.  Also, if no GEM has been
installed, you can signal the program with an invalid function signal, and
if the program should not access the trap, you either kill it, return EACCDN
or send it some other signal.

========================================================================
 That *could* lead to the opinion that a new mode should perhaps be restricted
to a real 68030. You could then happily define the fork() stuff to only work
in the new mode and discard it from the old modes. Very old software doesn't
use it anyways, and the newer one can easily be recompiled.
========================================================================

I've thought about this as well.  And I'm curious what everyone else thinks
about leaving this Unix-like domain to the 030s only.  Personally, I'd rather
not since I don't have an 030, but then again, I'm not the person that would
benefit much from the Unix domain anyway!!

========================================================================
> [new Malloc strategy]
> Only new programs would use it.  Others would use fixed memory as normal.
> So it could work without killing other programs.
========================================================================

I'm currently discussing this memory handle stuff with DMJ to see if there
is a possibility of emulating some of the function of an MMU in software
using this semaphore block-locking stuff.